Эдвард Йордон - Путь камикадзе [Смертельный марш]

51) Поскольку вполне вероятно, что ночной процесс ежедневного формирования версии потребует минимального человеческого вмешательства, будет полезным установить следующий порядок: любой программист, допустивший ошибку в коде, которая привела к аварийному завершению ежедневной сборки, удостаивается высокой чести наблюдать за очередной сборкой, пока не появится следующая жертва. Разумеется, такой порядок имеет как плюсы, так и минусы, но по крайней мере благодаря ему команда гораздо «ближе» знакомится с принципом ежедневной сборки проекта.

52) Поручите одному из программистов, который обычно приходит в офис рано утром, проверять успешность завершения ежедневной сборки и вывешивать результаты на видное место. Если ни у кого нет желания или возможности появляться в офисе рано утром, наймите студента колледжа. Одна компания велела студенту поднимать над офисом флаг, чтобы таким образом предупреждать сотрудников, какой день ожидается: плохой или хороший. Зелёный флаг означал успешное завершение процесса ежедневной сборки, а красный – аварийное завершение.

Если управление требованиями – особенно определение приоритетов требований – является в безнадёжном проекте наиболее важным процессом, то вторым важнейшим процессом является управление рисками. Если бы понятие «риска» не было столь критическим, тогда мы не употребляли бы по отношению к проекту определение «безнадёжный». Интересно отметить, что один из вопросов «теста на алкоголь» связан с идентификацией проектных рисков, и если ответом на такой вопрос со стороны менеджера «нормального» проекта может быть удивлённый взгляд (даже если проект оказался в плачевном состоянии), то менеджер безнадёжного проекта скорее всего даст на такой вопрос чёткий и ясный ответ. Менеджер был бы просто глупцом, если бы он приступил к безнадёжному проекту, не имея какого-либо серьёзного представления об основных рисках и о том, как с ними бороться.

Увы, но в ходе проекта ситуация может выйти из-под контроля. Это происходит потому, что управление рисками строится в основном на эмоциях и инстинктах, а не на формальных процессах, и менеджер зачастую может просто не заметить вовремя появление новых рисков в ходе проекта. В лучшем случае будут устраняться риски, которые являются очевидными в самом начале проекта; в нормальной ситуации они будут поводом для беспокойства в течение всего проекта (например, риск ухода ключевого разработчика). Однако, могут неожиданно возникнуть совершенно новые риски, которых никто не ожидал, и поскольку команда обычно обладает слишком малым запасом прочности (в терминах плана, бюджета и ресурсов), эти риски могут оказаться для проекта убийственными.

Если вся эта дискуссия относительно рисков разработки ПО кажется вам чересчур раздутой или вообще не относящейся к делу, можете смело переходить к следующей главе. Меня больше всего заботит менеджер проекта, который успешно завершил несколько «нормальных» проектов, справляясь с рисками на интуитивном уровне; такой подход в безнадёжном проекте обычно не работает. На самом деле, существуют эффективные формальные процессы управления рисками, позволяющие предпринимать безнадёжные проекты, которые в противном случае наверняка стали бы самоубийственными.

На тему об управлении рисками написана масса книг, их обзор не является предметом данной книги. Всю необходимую вам детальную информацию вы можете получить из первоисточников [4, 5, 6, 7], хотя важно остерегаться, чтобы «служба управления рисками» не погребла проект под формами, отчётами и другими бюрократическими штучками. Например, некоторые менеджеры безнадёжных проектов следуют очень простой практике идентификации и мониторинга десяти основных рисков проекта; их можно отпечатать на одной странице и еженедельно выполнять оперативный анализ их состояния.

Естественно, можно не менее успешно использовать и другие подходы, но самое главное – обеспечить, чтобы проектная команда их понимала, принимала и следовала им, поскольку рядовые сотрудники на самом нижнем уровне иерархии обычно первыми замечают появление новых рисков. В безнадёжном проекте некогда ждать, пока информация доберётся до руководства по безнадёжно устаревшим каналам; на проблему нужно навалиться всей командой и справиться с ней, пока она не вышла из-под контроля.

Слово «контроль» в данном случае является важным, поскольку проектная команда должна различать оценку риска, контроль риска и ликвидацию риска. В худшем случае проектная команда реагирует на риск только по мере его возникновения – например, выделяя дополнительные ресурсы для проведения дополнительного тестирования, чтобы смягчить последствия ошибки. Такой подход, когда проблеме уделяется внимание только после её проявления, часто приводит к авральной работе в стиле «тушения пожара», которая, в свою очередь, может оказаться для проектной команды просто катастрофой. Гораздо лучше предупреждать риск заранее, и это означает, что команда согласна соблюдать выполнение формальных процессов оценки и контроля с целью предотвращения потенциальных рисков.

Управление рисками в более профилактической форме направлено на устранение самих причин, приводящих к риску и неудачам; оно нередко является центральным звеном всех начинаний, связанных с управлением качеством в организации. При таком подходе проявляется тенденция к значительному расширению границ оценки рисков и появлению возможности их предотвращения ; это может привести к весьма агрессивному стилю управления, основанному на полном контроле над степенью риска в соответствии с его допустимостью для организации. Я всецело разделяю такой подход, однако эта проблема в большей степени стратегическая, она должна обсуждаться и реализовываться за пределами безнадёжного проекта. Команда безнадёжного проекта преследует в основном тактические цели; она не пытается изменить культуру организации, а всего лишь выжить и нормально закончить проект.

Тем не менее, могут возникнуть некоторые проблемы, связанные с культурой организации, особенно в том случае, если существует мнение, что в других проектах риск отсутствует, и данный проект – это первый, последний и единственный безнадёжный проект, когда-либо имевший место в организации. Проблема заключается в том, что проектная команда не находится на необитаемом острове; если бы это было так, то можно было бы решить все вопросы, «ликвидировав вестника», который докладывает о проблемах руководству.

С другой стороны, как отмечает Rob Charette [8], основные причины провалов проектов зачастую кроются в окружающей проект среде (среде самой организации и/или внешней среде), как показано на рис. 5.2. Эта среда почти всегда находится вне пределов досягаемости менеджера проекта, и что не менее важно, менеджер проекта может и не подозревать о наличии этих «внешних» рисков, пока они не обрушатся на проект.

Разумеется, верно и обратное: проект порождает риски, которые могут воздействовать на среду организации и внешнюю среду, и об этом знает каждый. В самом деле, менеджер проекта не должен забывать, что его безнадёжный проект может подвергнуть опасности всю организацию – если не цивилизацию и всю вселенную! Те менеджеры, которые плачутся и жалуются, что их команда трудится над завершением проекта всего лишь 127 часов в неделю, зачастую находятся в блаженном неведении относительно происходящего у них под носом, что может привести к крушению проекта.

Рис. 5.2 Область действия проектных рисков

Поэтому столь важно использовать формальные процессы управления рисками, с помощью которых можно оценить проектные риски по различным аспектам деятельности организации и попытаться отыскать разумный баланс между ними; в конце концов то, что кажется риском проектировщику и разработчику ПО, может рассматриваться департаментом маркетинга как благоприятная возможность. Такой подход к «глобальному» управлению рисками очень важен, но мне приходилось встречаться с ним в безнадёжных проектах совсем не так часто, как хотелось бы. Как было отмечено выше, у проектной команды нет времени, энергии или политического влияния, чтобы пытаться изменить культуру организации с помощью внедрения глобального процесса управления рисками. Следовательно, отсутствие такого процесса в организации само по себе становится риском, который команда должна оценить.

Оценка риска выполняется обычно путём оценки сложности разрабатываемой системы или продукта, а также оценки клиентской среды и среды проектной команды. Сложность продукта можно оценить в терминах объёма (например, количества функциональных точек), ограничений производительности, технической сложности и т.д. Риск, связанный с клиентской средой, определяется в основном такими факторами, как количество пользователей, вовлечённых в проект, уровень квалификации пользователей, значение разработки для пользовательского бизнеса, вероятность того, что внедрение новой системы (если оно произойдёт) приведёт к реорганизации или даунсайзингу и т.д. Наконец, риск, связанный со средой проектной команды, зависит от её способностей, опыта, морального состояния и физического/эмоционального здоровья.